The field of the invention is controller programming and communication and more specifically location based data management and automated programming of controllers/communication machines when controllers/machines are moved to facility locations in which the controllers/machines may be suitable to perform automated processes or sub-processes.
A visit to virtually any modern manufacturing facility in the world leaves room for little doubt that assembly/machine lines have become an integral part of the manufacturing process. Robots, computers, programmable logic controllers, mills, drills, stamps, clamps, sensors, transfer bars, assemblers, etc., are more numerous than people in most modern manufacturing facility. Automation has been widely embraced in great part because almost every industry has recognized that use of automated assembly/machine lines to form and assemble product components and assemblies reduces manufacturing time and product costs and increases product quality.
While automation has many advantages, one of the most important shortcomings associated with automation is that automated systems are relatively expensive to develop, construct and debug. Some efforts to reduce automation costs have focused on increasing the flexibility of the resources (e.g., machines, sensors, actuators, controllers, interfaces, etc.) used to construct and operate machine lines. Flexibility efforts have generally been focused on reducing costs by providing machines that can be controlled by a programmable controller or a group of cooperating distributed controllers to perform different machine cycles. For example, instead of maintaining several different types of single axis drill presses that are capable of performing different machining functions, a facility may obtain a single robot based multi-axis drilling machine that can be controlled to provide an array of desired capabilities. As another example, a pellet dryer for use in drying plastic pellets for use in a rotational molding process and an associated auger may be controlled to have different length drying cycles, different drying temperatures, different air flow rates, different agitation and auger speeds and so on to provide pellets that have ideal characteristics for any molding operation.
Yet one other example includes component insertion machines used to assemble printed circuit boards (PCBs). In the case of PCB assembly operations, a flexible insertion machine may include a multi-axis articulating arm controllable to perform many different movements and machinations such that circuit components can be moved along various paths toward their mounted positions. Multi-path capabilities are required in many cases as PCB components and machine parts may be differently juxtaposed in different applications and hence some paths that are clear in one application may be blocked in another application.
One other effort directed toward increasing system flexibility has been to render machines portable for easy movement within a facility. For example, the pellet dryer described above may be mounted on casters that facilitate easy movement about the facility from one rotational mold set up to another mold set up. For instance, a single dryer may be able to provide the drying function to a plurality of different mold set ups thereby reducing overall costs. For instance, assume five separate mold assemblies where each assembly performs a 30-minute molding cycle and the drying and pellet sub-cycles require only five minutes each. In this case, instead of using five separate dryer machines, one for each mold sub-set, molding cycles may be staggered and a single dryer machine may be moved between mold sub-sets to provide the drying requirement.
As another example, in the case of PCB assembly, component insertion machines may include casters for rapid movement from one facility location to another so that machine capabilities and different machine combinations can quickly be configured when required and the number of machines required to provide all capabilities can be appreciably minimized.
While automation flexibility works in theory, unfortunately, in reality, combining machines to facilitate automated processes is much more difficult than simply wheeling machines into relative proximity and activating the machines. For example, assume eighty machines are to be combined with twenty distributed controllers to perform a process where the controllers are linked together via a network (e.g., an Ethernet). In this example an operator (or group of operators) charged with configuring, commissioning and programming the machine group faces several challenges including placement of the machines in correct relative juxtapositions, linking machines appropriately to input/output terminals of respective controllers and providing program code to each controller to control associated machines. The industry has developed tools to help operators meet these challenges such as machine layout maps that indicate required machine juxtapositions, I/O maps that indicate required I/O linkages and control programs that have separate code segments earmarked for each of the separate controllers and that can be downloaded into the separate controllers after the controllers and related machines are associated with specific parts of a manufacturing process.
While each of these tools has proven valuable in the past, each of the tools has several shortcomings. For instance, in the example above including eighty machines and twenty controllers, assume that two of the machines include first and second identical PCB insertion machines that are to be placed next to each other along a transfer line but that each of the insertion machines is to perform a different insertion process where the process performed by the second machine must be performed after the process performed by the first machine. Here, if the wrong program code segments are loaded into each of the first and second machines a configuration/programming error may occur which may not be identified until a commissioning procedure is performed. Similar problems can occur where I/O linkages are incorrectly formed such that required signals are never transmitted or received by respective controllers.
One other challenge facing the operator in the above example is to make sure that all of the machine cycles required to facilitate a process are properly sequenced. In this regard, as well known in the controls art, to avoid damage to machine components and ensure that processes are performed in the correct sequence, often cycles to be performed by one machine must be tied to completion of other machine cycles. For instance, a PCB insertion machine for inserting a circuit on a board at an insertion station must not begin an insertion cycle until after a transfer line adjacent thereto has moved a board to an appropriate location at the insertion station. As another instance, where there are two different insertion machines at a single insertion station where machine components (e.g., robotic arms) have to move into the same space above the board at different and interleave times to perform various insertion cycles, machine cycles have to be consecutively sequenced to avoid damage to the robotic arms.
Sequencing is typically performed by providing some way for distributed controllers to exchange information related to the status of the machines being controlled by the controllers. For instance, in the case above where an insertion cycle is tied to transfer line movement, a transfer line cycle complete or parked signal may be required by the controller controlling the insertion machine prior to beginning the insertion cycle. Similarly, prior to initiating a transfer line movement a controller controlling a transfer line may require cycle complete or parked signals form each of the machines juxtaposed adjacent the transfer line. Information or data requirements are typically defined by the program code segments that are performed by the separate distributed controllers.
One way to exchange information between controllers is to program the controllers to actually address specific information to other specific controllers that need the information. For instance, in the case of an Ethernet network where each controller linked to the network includes its own unique address, parked signals can be directed to specific controllers that have require the information to perform some function. For example, in the case above where each of the transfer line and the second insertion machine require cycle complete and/or partial cycle complete signals from the first insertion machine, the controller controlling the first machine may be programmed to address required signals to each of the second insertion machine and the transfer line. Transfer systems where controllers specifically address data to other controllers will be referred to generally hereinafter as point-to-point systems.
Unfortunately point-to-point systems have several shortcomings. First, point-to-point systems complicate the controller programming task appreciably. In this regard, assume in the above example that seventy-nine of the eighty machines and nineteen of the twenty distributed controllers required to perform the process have been configured and that an insertion machine including its own distributed processor is retrieved to be added as the eightieth machine and twentieth controller. Here, in addition to positioning the eightieth machine, forming proper I/O linkages and providing the proper program code segment for the machine, the operator has to identify the Ethernet address of the insertion machine to be added and use that address to alter the program code segments performed by the other controllers that have to send data to the insertion machine's controller.
In addition, each of the addresses of the other controllers that requires information from the insertion machine's controller must also be identified and used to alter the insertion machine controller's program to address information to the other controllers. While this data addressing process may not be too burdensome in simple cases where there are only a small number of controllers, unfortunately complex automated systems may include tens or even hundreds of distributed controllers where each of the controllers may generate hundreds or even thousands of signals that have to be provided to other controllers and each of the controllers may require hundreds or even thousands of signals form other controllers. Thus, in many cases the task of addressing data between controllers is daunting.
Second, because point-to-point data addressing is cumbersome, such addressing can lead to many programming and mapping errors which appreciably complicates program debugging processes. Third, where specific data is required by many controllers, point-to-point data addressing requires excessive amounts of communication bandwidth as the same data must be transmitted separately from the source controller to each of the destination controllers. Fourth, where point-to-point communication schemes are employed it is difficult to synchronize machine operations as data arrives at receiving destination controllers at different times.
One solution for reducing bandwidth required to provide data to multiple controllers and to address some of the other shortcomings of point-to-point communication systems has been to adopt a producer/consumer communication protocol. Generally, according to producer/consumer protocols, instead of earmarking data for delivery to specific destination controllers, data producers effectively mark data with “tags” that indicate the content of the associated data and broadcast the tagged data generally onto a communication network (e.g., an Ethernet). Thereafter, “consumer” controllers monitor the network for data having a tag indicating a particular type (e.g., data tagged to indicate content required by the consumer) of data and, when a required data type is identified, as the label implies, consume or use the tagged data to perform a related function. Data not required by a controller is simply ignored (i.e., is not consumed).
In addition to reducing required communication bandwidth, producer/consumer protocols minimize synchronization problems as multiple consumers can receive the same data at essentially the same time.
While producer/consumer communication protocols solve several of the problems associated with point-to-point communication protocols, unfortunately producer/consumer protocols typically do not eliminate the need for operators to specify controller addresses required for data tagging purposes. To this end, in most cases, consumer controllers require data (e.g., cycle or partial cycle complete signals, etc.) from specific other controllers. For instance, in the example above where an insertion machine with its own controller is being added to a pre-configured group of seventy-nine other machines and nineteen other distributed controllers, the insertion machine may initiate an insertion cycle when a parked signal from the controller controlling the transfer line is received. Here the transfer line controller must provide a parked signal on the network that is tagged so that other controllers, including the insertion machine controller, can identify the parked signal as being from the transfer line controller. In most cases this signal-producer controller association is facilitated by tagging the transfer line parked data with the transfer line controller network address and programming the insertion machine controller to consume parked signals tagged with the transfer line controller's address. Similarly, the insertion machine controller may require signals form many (e.g., 10) other controllers for sequencing purposes and hence may require other controller addresses to facilitate data consumption.
Also, ten of the twenty system controllers may require signals from the insertion machine controller to facilitate sequencing. Here, the address of the insertion machine controller must be provided to each of the other ten controllers to facilitate listening for data tagged as produced by the insertion machine controller.
Most large automated facilities include several instances of many machine types used in the facilities where each of the instances may have different characteristics. For example, a single facility that routinely performs PCB fabrication procedures may use ten different PCB insertion machine instances where each of the machine instances has a different set of sensors and actuators, a different physical foot print, has different movement and insertion capabilities, etc. In addition, in many cases any of several different instances of the same machine type may be useable with other machines to perform a single process.
Where several different instances of machine types are used within a single facility, all of the tasks associated with combining groups of machines and controllers to perform processes are further complicated. For instance, again assuming that an insertion machine with its own controller is being added to seventy-nine other machines and nineteen other controllers to perform a process. Also assume that there are first and second different instances of the insertion machine type where the different instances have disparate physical and operational characteristics. Here, while it may be appropriate to position the first machine instance at one location with respect to the other machines, it may be inappropriate to position the second machine instance at the same location due to differences in the physical footprints of the machines, space required for machine movements, I/O terminal requirements, etc.
In addition, because the first and second insertion machine instances have different compliments of sensors and actuators and have different movement capabilities, the program code segments required to control each of the insertion machines may be different. Similarly, the different program codes may require different sequencing data from the other nineteen distributed controllers to perform sequences. For instance, the first insertion machine may require only one transfer line parked signal from a transfer line controller while the second machine may require both the parked signal from the transfer line controller and a second parked signal from a redundant controller that monitors transfer line operation. Here, the operator must have knowledge about the sequencing requirements of each of the insertion machines and the addresses of the transfer line controller and the redundant controller so that the operator can provide the required address information to the controller of the selected insertion machine for listening on the network to identify properly tagged data to be consumed by the insertion machine controller.
One other feature of some automated systems that complicates configuration tasks is that various facility machines and controllers may be controlled in different ways to perform a sub-process or to control different sub-processes as a function of the characteristics of the compliment of machines associated with a particular process. For instance, in the example above where one of first and second insertion machine instances is to be combined with other machines to perform a process, at least some of the other machines may be programmable to alter sequencing requirements as a function of which of the first or second insertion machine instances is added to the combination. For example, the controller included with the first insertion machine instance may provide partial cycle complete signals as well as a cycle complete signal while the controller included with the second insertion machine instance only provides a cycle complete signal. Here, on one hand, when the first machine instance is added to the other machines to perform a process, it may be optimal that another machine in the combination be programmed to monitor the network for partial cycle complete signals from the first machine controller so that cycles performed by the other machine can be sequenced at least in part in parallel with the first machine cycle thereby speeding up completion of the overall process. On the other hand, when the second insertion machine instance is added to the machine combination to perform the process, the other machine may simply monitor for the cycle complete signal and consume that signal accordingly. Here, the operator must have knowledge of operational capabilities and associated data requirements of each machine used in a facility so that optimal program code segments can be selected for each distributed controller and to facilitate proper producer/consumer communication.
Yet one other complicating feature of some automated systems is that operational requirements of a specific machine/controller to perform a process in conjunction with other machines and controllers may be different depending upon location or relative juxtaposition with respect to the other machines/controllers. For example, in some cases an operator may have the option to configure a set of machines including a PCB insertion machine in either one of the two different configurations to produce the same end product. In one configuration the PCB insertion machine may be positionable along with other machines at a first station along a transfer line where several machines perform their subprocesses in parallel. In the second configuration the PCB insertion machine may be positionable alone at a second station along the transfer line to perform its sub-process after the other machines have completed their sub-processes. Here, the movements and cycle sequencing of the PCB insertion machine in the two configurations are completely different and hence different code and data mapping are required.
Thus, it would be advantageous to have a system that can aid facility operators in configuring specific machine/controller combinations quickly, precisely and optimally to perform automated processes, that reduces programming errors and that reduces the skill set required by operators charged with performing configuration processes.